-
Notifications
You must be signed in to change notification settings - Fork 951
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added mechanism to determine if server did not start cleanly #1539
Conversation
The patch looks good, except it breaks a bunch of tests for some reason, please fix that. |
Sure I'll look into it. @janiversen i'm wondering whether it's better to set(False) or set the exception. I'm not 100% sure myself. |
Setting an exception is strange, you could raise an exception. |
@janiversen I think that's what I mean. This could be written so that one or the other of these works: if not await connection.serving:
# Handle failed connection
... try:
await connection.serving
except IOError:
# Handle failed connection
... The difference in this PR is between: except:
self.serving.set_result(False)
raise except IOError:
self.serving.set_exception(sys.exc_info()[1])
raise |
The last can be made a lot easier: except IOError as exc:
self.serving.set_exception(exc)
raise But independent of that:
|
Cleaned up the PR. |
Apologies for not getting back sooner. It's been a busy few weeks. |
I added a new future: serving_done. Your concept could not work, because you cannot do set_result() on a future one, not multiple times. |
Just to check that serving_done would fit the need, the aim is to have a single code path complete on success or failure. The problem with the existing design was that you could not "continue when server ready":
so no single code path is certain to continue on both success and failure... here continue does not need to be success, it could be continue by raising an exception but it must exit and not await indefinitely. It's particularly problematic in unit tests, but has other uses. |
Same rationale as #715. I wonder if it got accidentally removed in the great 3.rewrite or if it was deliberately removed.
The key issue is starting a server and waiting for it to be up, also requires the unhappy path to be handled in determining that it will not come up.